بوابة واجهة برمجة تطبيقات الواجهة الأمامية: اتحاد GraphQL وتجميع المخططات

في عالم تطوير تطبيقات الويب الحديثة، يمكن أن تشكل إدارة البيانات من مصادر متعددة تحديًا كبيرًا. مع نمو التطبيقات في التعقيد وتبنيها لهياكل الخدمات المصغرة (microservices)، تصبح الحاجة إلى طريقة موحدة وفعالة للوصول إلى البيانات أمرًا بالغ الأهمية. تعمل بوابة واجهة برمجة تطبيقات الواجهة الأمامية (Frontend API Gateway) كنقطة دخول مركزية لتطبيقات العميل، حيث تقوم بتجميع البيانات من خدمات الواجهة الخلفية المختلفة وتوفير تجربة مبسطة للمطورين والمستخدمين النهائيين على حد سواء. يستكشف هذا المقال تقنيتين قويتين لبناء بوابة واجهة برمجة تطبيقات الواجهة الأمامية: اتحاد GraphQL (GraphQL Federation) وتجميع المخططات (Schema Stitching).

ما هي بوابة واجهة برمجة تطبيقات الواجهة الأمامية؟

بوابة واجهة برمجة تطبيقات الواجهة الأمامية هي نمط معماري يعمل فيه خادم مخصص كوسيط بين عملاء الواجهة الأمامية (مثل متصفحات الويب وتطبيقات الجوال) وخدمات الواجهة الخلفية المتعددة. إنها تبسط عملية جلب البيانات عن طريق:

• تجميع البيانات: دمج البيانات من مصادر متعددة في استجابة واحدة.
• تحويل البيانات: تكييف تنسيقات البيانات لتناسب احتياجات الواجهة الأمامية.
• تجريد التعقيد: إخفاء تعقيدات خدمات الواجهة الخلفية عن العميل.
• فرض الأمان: تنفيذ سياسات المصادقة والتفويض.
• تحسين الأداء: التخزين المؤقت للبيانات التي يتم الوصول إليها بشكل متكرر وتقليل طلبات الشبكة.

بشكل أساسي، تطبق نمط الواجهة الخلفية للواجهة الأمامية (BFF) على نطاق واسع وتمكّن فرق الواجهة الأمامية من التحكم بشكل أكبر في واجهات برمجة التطبيقات التي يستهلكونها. في المؤسسات الكبيرة، يمكن أن يؤدي قيام الواجهة الأمامية بإدارة وتنظيم واجهات برمجة التطبيقات الخاصة بها إلى تسليم أسرع وتقليل الاعتماد على فرق الواجهة الخلفية.

لماذا نستخدم GraphQL لبوابة واجهة برمجة تطبيقات الواجهة الأمامية؟

GraphQL هي لغة استعلام لواجهات برمجة التطبيقات ووقت تشغيل لتلبية هذه الاستعلامات ببياناتك الحالية. إنها توفر العديد من المزايا مقارنة بواجهات برمجة التطبيقات REST التقليدية، مما يجعلها مناسبة تمامًا لبناء بوابات واجهة برمجة تطبيقات الواجهة الأمامية:

• جلب فعال للبيانات: يطلب العملاء البيانات التي يحتاجونها فقط، مما يقلل من الجلب الزائد (over-fetching) ويحسن الأداء.
• كتابة قوية (Strong typing): تحدد مخططات GraphQL بنية البيانات، مما يتيح أدوات وتحققًا أفضل.
• الاستبطان (Introspection): يمكن للعملاء اكتشاف البيانات والعمليات المتاحة من خلال استبطان المخطط.
• قدرات في الوقت الفعلي: تتيح اشتراكات GraphQL تحديثات البيانات في الوقت الفعلي.

من خلال الاستفادة من GraphQL، يمكن لبوابة واجهة برمجة تطبيقات الواجهة الأمامية توفير واجهة مرنة وفعالة وسهلة للمطورين للوصول إلى البيانات من خدمات الواجهة الخلفية المتعددة. يتناقض هذا بشكل حاد مع الأساليب التقليدية التي تستخدم نقاط نهاية REST متعددة، حيث يحتاج كل منها إلى الاستعلام بشكل فردي وغالبًا ما يعيد بيانات أكثر من المطلوب.

اتحاد GraphQL: نهج موزع

ما هو اتحاد GraphQL؟

اتحاد GraphQL هو تقنية قوية لبناء واجهة برمجة تطبيقات GraphQL موزعة عن طريق تكوين خدمات GraphQL متعددة (تسمى "المخططات الفرعية" أو "subgraphs") في مخطط واحد وموحد. كل مخطط فرعي مسؤول عن مجال أو مصدر بيانات معين، وتقوم بوابة الاتحاد بتنسيق الاستعلامات عبر هذه المخططات الفرعية.

يدور المفهوم الأساسي حول المخطط الفائق (supergraph)، وهو مخطط GraphQL واحد وموحد يمثل واجهة برمجة التطبيقات بأكملها. يتم بناء هذا المخطط الفائق من خلال تكوين مخططات GraphQL أصغر، تسمى المخططات الفرعية (subgraphs)، يمثل كل منها خدمة مصغرة أو مصدر بيانات معين. بوابة الاتحاد مسؤولة عن توجيه استعلامات GraphQL الواردة إلى المخططات الفرعية المناسبة ودمج النتائج في استجابة واحدة.

كيف يعمل اتحاد GraphQL

1. تعريف المخطط الفرعي: تعرض كل خدمة مصغرة واجهة برمجة تطبيقات GraphQL (مخطط فرعي) تحدد بياناتها وعملياتها الخاصة. تتضمن هذه المخططات توجيهات (directives) تخبر بوابة الاتحاد بكيفية حل الأنواع والحقول. تشمل التوجيهات الرئيسية `@key` و `@external` و `@requires`.
2. تكوين المخطط الفائق: تسترد بوابة الاتحاد (مثل Apollo Gateway) المخططات من كل مخطط فرعي وتكوّنها في مخطط واحد وموحد (المخطط الفائق). تتضمن هذه العملية حل تعارضات الأنواع والحقول وإنشاء علاقات بين الأنواع عبر المخططات الفرعية المختلفة.
3. تخطيط الاستعلام وتنفيذه: عندما يرسل العميل استعلام GraphQL إلى البوابة، تقوم البوابة بتحليل الاستعلام وتحديد المخططات الفرعية التي يجب الاستعلام عنها لتلبية الطلب. ثم توزع الاستعلام على المخططات الفرعية المناسبة، وتجمع النتائج، وتدمجها في استجابة واحدة، والتي يتم إرجاعها إلى العميل.

مثال: منصة تجارة إلكترونية مع اتحاد GraphQL

لنفترض وجود منصة تجارة إلكترونية بها خدمات مصغرة منفصلة للمنتجات والعملاء والطلبات.

• المخطط الفرعي للمنتجات: يدير معلومات المنتج (الاسم، الوصف، السعر، إلخ).
• المخطط الفرعي للعملاء: يدير بيانات العملاء (الاسم، العنوان، البريد الإلكتروني، إلخ).
• المخطط الفرعي للطلبات: يدير معلومات الطلب (معرف الطلب، معرف العميل، معرفات المنتجات، المبلغ الإجمالي، إلخ).

يعرض كل مخطط فرعي واجهة برمجة تطبيقات GraphQL، وتقوم بوابة الاتحاد بتكوين هذه الواجهات في مخطط فائق واحد. يمكن للعميل بعد ذلك الاستعلام عن المخطط الفائق لاسترداد معلومات حول المنتجات والعملاء والطلبات في طلب واحد.

على سبيل المثال، يمكن أن يبدو الاستعلام لاسترداد اسم العميل وسجل طلباته كما يلي:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

ستقوم بوابة الاتحاد بتوجيه هذا الاستعلام إلى المخططات الفرعية للعملاء والطلبات، واسترداد البيانات اللازمة، ودمجها في استجابة واحدة.

فوائد اتحاد GraphQL

• تبسيط الوصول إلى البيانات: يتفاعل العملاء مع نقطة نهاية GraphQL واحدة، بغض النظر عن مصادر البيانات الأساسية.
• تحسين الأداء: يتم تحسين جلب البيانات عن طريق استرداد البيانات الضرورية فقط من كل مخطط فرعي.
• زيادة قابلية التوسع: يمكن توسيع كل مخطط فرعي بشكل مستقل، مما يسمح باستخدام أفضل للموارد.
• التطوير اللامركزي: يمكن للفرق تطوير ونشر المخططات الفرعية بشكل مستقل، مما يعزز المرونة والابتكار.
• حوكمة المخطط: تفرض بوابة الاتحاد اتساق المخطط وتوافقه عبر المخططات الفرعية.

أدوات اتحاد GraphQL

• Apollo Federation: تطبيق مفتوح المصدر شائع لاتحاد GraphQL، يوفر بوابة وسجل مخططات وأدوات لبناء وإدارة واجهات GraphQL الموحدة. يُعرف Apollo Federation بقابليته للتوسع ومعالجته القوية للأخطاء.
• GraphQL Hive: توفر هذه الأداة سجل مخططات وحوكمة لخدمات GraphQL الموحدة، وتقدم ميزات مثل اكتشاف التغيير، وتحليل الاستخدام، وفحص المخططات. إنها تعزز الرؤية والتحكم في المخطط الفائق.

تجميع المخططات: نهج بديل

ما هو تجميع المخططات؟

تجميع المخططات (Schema Stitching) هو تقنية أخرى لدمج مخططات GraphQL متعددة في مخطط واحد وموحد. على عكس الاتحاد، يتضمن تجميع المخططات عادةً عملية يدوية أكثر لتحديد كيفية ربط الأنواع والحقول من المخططات المختلفة. بينما يعتبر الاتحاد حلاً أكثر حداثة وقوة، يمكن أن يكون تجميع المخططات خيارًا قابلاً للتطبيق لحالات الاستخدام الأبسط أو عند الترحيل من واجهات برمجة تطبيقات GraphQL الحالية.

كيف يعمل تجميع المخططات

1. تعريف المخطط: تعرض كل خدمة مصغرة واجهة برمجة تطبيقات GraphQL بمخططها الخاص.
2. منطق التجميع: تحدد طبقة التجميع (غالبًا ما يتم تنفيذها باستخدام مكتبات مثل GraphQL Tools) كيفية ربط الأنواع والحقول من المخططات المختلفة. يتضمن ذلك كتابة دوال المحللات (resolver functions) التي تجلب البيانات من الخدمات الأساسية وتعينها إلى المخطط الموحد.
3. المخطط الموحد: تجمع طبقة التجميع المخططات الفردية في مخطط واحد وموحد يتم عرضه للعميل.

مثال: تجميع المنتجات والمراجعات

تخيل خدمتي GraphQL منفصلتين: واحدة للمنتجات وأخرى للمراجعات.

• خدمة المنتجات: توفر معلومات حول المنتجات (المعرف، الاسم، الوصف، السعر).
• خدمة المراجعات: توفر مراجعات للمنتجات (المعرف، معرف المنتج، التقييم، التعليق).

باستخدام تجميع المخططات، يمكنك إنشاء مخطط موحد يسمح للعملاء باسترداد معلومات المنتج والمراجعات في استعلام واحد.

ستقوم بتعريف دالة محلل في طبقة التجميع تجلب المراجعات لمعرف منتج معين من خدمة المراجعات وتضيفها إلى نوع المنتج (Product) في المخطط الموحد.

// مثال (مفاهيمي): منطق التجميع باستخدام GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // تعريف مخطط المنتجات الخاص بك
const reviewsSchema = ... // تعريف مخطط المراجعات الخاص بك

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // جلب المراجعات للمنتج من خدمة المراجعات
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

يوضح هذا المثال المفهوم الأساسي لتجميع المخططات معًا. لاحظ الحاجة إلى محللات (resolvers) مخصصة لجلب حقل reviews. يمكن أن يؤدي هذا العبء الإضافي لترميز المحللات لكل علاقة إلى إبطاء عملية التطوير مقارنةً باستخدام الاتحاد.

فوائد تجميع المخططات

• واجهة برمجة تطبيقات موحدة: يصل العملاء إلى نقطة نهاية GraphQL واحدة، مما يبسط الوصول إلى البيانات.
• التبني التدريجي: يمكن تنفيذ تجميع المخططات بشكل تدريجي، مما يسمح لك بالانتقال تدريجيًا إلى واجهة برمجة تطبيقات موحدة.
• المرونة: يوفر تجميع المخططات مزيدًا من التحكم في كيفية دمج المخططات، مما يسمح لك بتخصيص منطق التجميع لتلبية احتياجات محددة.

عيوب تجميع المخططات

• التكوين اليدوي: يتطلب تجميع المخططات تكوينًا يدويًا لمنطق التجميع، والذي يمكن أن يكون معقدًا ويستغرق وقتًا طويلاً.
• عبء الأداء: يمكن أن تؤدي دوال المحللات إلى عبء على الأداء، خاصةً إذا كانت تتضمن تحويلات بيانات معقدة.
• قابلية توسع محدودة: قد يكون من الصعب توسيع نطاق تجميع المخططات مقارنة بالاتحاد، حيث يكون منطق التجميع مركزيًا عادةً.
• ملكية المخطط: يمكن أن يؤدي إلى غموض حول ملكية المخطط، خاصةً إذا كانت فرق مختلفة تدير الخدمات المجمعة.

أدوات تجميع المخططات

• GraphQL Tools: مكتبة شائعة لبناء ومعالجة مخططات GraphQL، بما في ذلك دعم تجميع المخططات.
• GraphQL Mesh: يسمح لك GraphQL Mesh باستخدام لغة استعلام GraphQL للوصول إلى البيانات من مصادر مختلفة مثل واجهات برمجة تطبيقات REST وقواعد البيانات و gRPC. يمكنه تجميع هذه الواجهات في مخطط GraphQL موحد.

اتحاد GraphQL مقابل تجميع المخططات: مقارنة

يقدم كل من اتحاد GraphQL وتجميع المخططات طرقًا لدمج مخططات GraphQL متعددة في واجهة برمجة تطبيقات واحدة، لكنهما يختلفان في نهجهما وقدراتهما.

الميزة	اتحاد GraphQL	تجميع المخططات
النهج	تكوين موزع وتلقائي	تكوين مركزي ويدوي
التعقيد	تعقيد أقل للصيانة والتوسع	تعقيد أعلى بسبب منطق المحللات اليدوي
قابلية التوسع	مصمم للأنظمة الموزعة واسعة النطاق	أقل قابلية للتوسع، يستخدم عادةً للتطبيقات الأصغر
حوكمة المخطط	حوكمة وتحقق مدمجان للمخطط	يتطلب إدارة وتنسيق يدوي للمخطط
الأدوات	نظام بيئي قوي من الأدوات والمكتبات (مثل Apollo Federation)	يتطلب المزيد من الأدوات والتكوين المخصص
حالات الاستخدام	هياكل الخدمات المصغرة، واجهات برمجة التطبيقات واسعة النطاق، التطوير اللامركزي	التطبيقات الأصغر، الترحيل التدريجي، متطلبات التخصيص المحددة

متى تستخدم اتحاد GraphQL: اختر الاتحاد عندما يكون لديك بنية خدمات مصغرة معقدة، وتحتاج إلى توسيع نطاق واجهة برمجة التطبيقات الخاصة بك، وترغب في تمكين فرق مستقلة من إدارة مخططاتها الفرعية الخاصة. كما أنه يبسط إدارة المخطط وحوكمته.

متى تستخدم تجميع المخططات: فكر في تجميع المخططات عندما يكون لديك واجهة برمجة تطبيقات أبسط، أو تحتاج إلى مزيد من التحكم في منطق التجميع، أو تقوم بالترحيل من واجهات برمجة تطبيقات GraphQL الحالية. ومع ذلك، كن على دراية بالتعقيدات المحتملة وقيود قابلية التوسع.

تنفيذ المصادقة والتفويض

بغض النظر عما إذا كنت تختار اتحاد GraphQL أو تجميع المخططات، فإن تنفيذ المصادقة والتفويض أمر بالغ الأهمية لتأمين بوابة واجهة برمجة تطبيقات الواجهة الأمامية الخاصة بك. هناك العديد من الأساليب التي يمكنك اتخاذها:

• المصادقة على مستوى البوابة: تتعامل بوابة واجهة برمجة التطبيقات مع المصادقة والتفويض قبل توجيه الطلبات إلى خدمات الواجهة الخلفية. يركز هذا النهج منطق الأمان ويبسط خدمات الواجهة الخلفية. تشمل الطرق الشائعة التحقق من صحة JWT (JSON Web Token) و OAuth 2.0.
• المصادقة على مستوى الخدمة: تتعامل كل خدمة خلفية مع المصادقة والتفويض الخاص بها. يوفر هذا النهج تحكمًا أكثر دقة في الأمان ولكنه قد يكون أكثر تعقيدًا في الإدارة.
• النهج الهجين: مزيج من المصادقة على مستوى البوابة والخدمة. تتعامل البوابة مع المصادقة الأولية، وتقوم خدمات الواجهة الخلفية بإجراء فحوصات تفويض أكثر دقة.

مثال: مصادقة JWT مع Apollo Federation

مع Apollo Federation، يمكنك تكوين البوابة للتحقق من صحة رموز JWT المضمنة في رؤوس الطلب. يمكن للبوابة بعد ذلك تمرير معلومات المستخدم المستخرجة من الرمز المميز إلى المخططات الفرعية، والتي يمكنها استخدام هذه المعلومات للتفويض.

// مثال (مفاهيمي): تكوين Apollo Gateway مع التحقق من صحة JWT
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... تكوينات المخططات الفرعية الخاصة بك
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // اسم المخطط الفرعي
      url,   // عنوان URL للمخطط الفرعي
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // الحصول على المستخدم من السياق
    const user = context.user;

    // إضافة معرف المستخدم إلى رؤوس الطلب
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

في هذا المثال، يتم إنشاء خدمة مخصصة لتعديل الطلبات الصادرة لتضمين معرف المستخدم المشتق من JWT. يمكن للخدمات النهائية بعد ذلك استخدام هذا المعرف لفحوصات التفويض.

استراتيجيات التخزين المؤقت لتحسين الأداء

التخزين المؤقت (Caching) ضروري لتحسين أداء بوابة واجهة برمجة تطبيقات الواجهة الأمامية. من خلال التخزين المؤقت للبيانات التي يتم الوصول إليها بشكل متكرر، يمكنك تقليل الحمل على خدمات الواجهة الخلفية وتحسين أوقات الاستجابة للعملاء. إليك بعض استراتيجيات التخزين المؤقت:

• التخزين المؤقت لـ HTTP: استفد من آليات التخزين المؤقت لـ HTTP (مثل رؤوس `Cache-Control`) لتخزين الاستجابات مؤقتًا في المتصفح والوكلاء الوسيطين.
• التخزين المؤقت في الذاكرة: استخدم ذاكرات التخزين المؤقت في الذاكرة (مثل Redis، Memcached) لتخزين البيانات التي يتم الوصول إليها بشكل متكرر على البوابة.
• التخزين المؤقت لشبكة توصيل المحتوى (CDN): استخدم شبكات توصيل المحتوى (CDNs) لتخزين الأصول الثابتة واستجابات واجهة برمجة التطبيقات بشكل أقرب إلى العميل.
• التخزين المؤقت لاستعلامات GraphQL: قم بتخزين نتائج استعلامات GraphQL مؤقتًا بناءً على سلسلة الاستعلام والمتغيرات الخاصة بها. يمكن أن يكون هذا فعالاً بشكل خاص للاستعلامات التي يتم تنفيذها بشكل متكرر. يوفر Apollo Server دعمًا مدمجًا للتخزين المؤقت للاستعلامات.

عند تنفيذ التخزين المؤقت، ضع في اعتبارك استراتيجيات إبطال ذاكرة التخزين المؤقت لضمان حصول العملاء على بيانات محدثة. تشمل الاستراتيجيات الشائعة ما يلي:

• انتهاء الصلاحية المستند إلى الوقت: قم بتعيين وقت انتهاء صلاحية ثابت للبيانات المخزنة مؤقتًا.
• الإبطال المستند إلى الأحداث: قم بإبطال ذاكرة التخزين المؤقت عندما تتغير البيانات في خدمات الواجهة الخلفية. يمكن تحقيق ذلك باستخدام webhooks أو قوائم انتظار الرسائل.

المراقبة والرصد

تعد المراقبة والرصد (Monitoring and Observability) أمرين حاسمين لضمان صحة وأداء بوابة واجهة برمجة تطبيقات الواجهة الأمامية الخاصة بك. قم بتنفيذ مراقبة شاملة لتتبع المقاييس الرئيسية مثل:

• زمن استجابة الطلب: الوقت الذي يستغرقه معالجة الطلب.
• معدلات الخطأ: النسبة المئوية للطلبات التي تؤدي إلى أخطاء.
• الإنتاجية: عدد الطلبات التي تتم معالجتها لكل وحدة زمنية.
• استخدام الموارد: استخدام وحدة المعالجة المركزية والذاكرة والشبكة للبوابة وخدمات الواجهة الخلفية.

استخدم التتبع (tracing) لتتبع الطلبات أثناء تدفقها عبر النظام، وتحديد الاختناقات ومشكلات الأداء. يوفر التسجيل (logging) رؤى قيمة حول سلوك البوابة وخدمات الواجهة الخلفية.

تشمل أدوات المراقبة والرصد ما يلي:

• Prometheus: نظام مراقبة وتنبيه مفتوح المصدر.
• Grafana: أداة لتصور البيانات والمراقبة.
• Jaeger: نظام تتبع موزع مفتوح المصدر.
• Datadog: منصة مراقبة وأمان للتطبيقات السحابية.
• New Relic: منصة ذكاء رقمي لمراقبة وتحسين أداء البرامج.

من خلال تنفيذ مراقبة ورصد قويين، يمكنك تحديد المشكلات وحلها بشكل استباقي، مما يضمن موثوقية وأداء بوابة واجهة برمجة تطبيقات الواجهة الأمامية الخاصة بك.

الخاتمة

يمكن لبوابة واجهة برمجة تطبيقات الواجهة الأمامية المبنية باستخدام اتحاد GraphQL أو تجميع المخططات أن تبسط بشكل كبير الوصول إلى البيانات، وتحسن الأداء، وتعزز تجربة المطور في تطبيقات الويب الحديثة. يوفر اتحاد GraphQL حلاً قويًا وقابلاً للتوسع لتكوين واجهات برمجة تطبيقات GraphQL موزعة، بينما يقدم تجميع المخططات نهجًا أكثر مرونة لدمج المخططات الحالية. من خلال النظر بعناية في المتطلبات المحددة لتطبيقك والمفاضلات بين هذه التقنيات، يمكنك اختيار أفضل نهج لبناء بوابة واجهة برمجة تطبيقات أمامية قوية وفعالة.

تذكر تنفيذ المصادقة والتفويض المناسبين، واستراتيجيات التخزين المؤقت، والمراقبة والرصد لضمان أمان وأداء وموثوقية بوابتك. من خلال تبني أفضل الممارسات هذه، يمكنك إطلاق العنان للإمكانات الكاملة لـ GraphQL وبناء تطبيقات ويب حديثة تقدم تجارب مستخدم استثنائية.